Hoy he topado con un artículo titulado Indra deja desiertos 800 puestos en España por falta de mano de obra cualificada que me recuerda demasiado a un debate de 2012 entre Enrique Dans, David Bonilla y José Manuel Beas. ¿Qué pasó con el programador perdido?

Casi como cada año comencé este año 2019 en procesos de selección. Después de pasar muchas veces por esto creo que puede ser interesante compartir cómo fue esta vez mi proceso. ¿Buscamos trabajo?

El libro Holacracia de Brian Robertson no solo aporta una visión diferente a la forma de organizar la empresa sino también a la forma de realizar las cosas por parte de cada trabajador y la interacción entre los mismos. En este artículo voy a centrarme en las reuniones. En Holacracia estas interacciones son las más beneficadas, ¿sabes por qué?

Hace tiempo escribí una entrada sobre la posibilidad de utilizar XMPP como elemento para SOA (service oriented arquitecture, arquitectura orientada al servicio), hoy vuelvo de nuevo con la idea y amplio un poco más gracias a este artículo (en inglés) que me ha llamado la atención sobre el hecho, ya no solo como sistema SOA, sino también como ESB (enterprise service bus, bús de servicio empresarial), para mantener comunicación entre todos los recursos de un sistema de la información.

No hay garantías hoy en día cuando un aspirante accede a una entrevista de trabajo. Los títulos y las certificaciones dependen de quién los emite y aún así en el caso de los títulos no constituyen una fuente fiable para certificar ciertos conocimientos. Entonces, ¿cómo podemos evaluar los conocimientos de estas personas de una forma justa? ¿Cómo encontramos al candidato adecuado?

Llevo tiempo pensando que quizás retribuir a un programador por horas es tirar el dinero. Esto no quiere decir que sea algo bueno o malo. Hay programadores de todo tipo. Los hay que cada hora pagada está invertida provechosamente para la empresa y también lo contrario. Pero, ¿realmente es buena idea pagar por esa hora? ¿No hay otra forma mejor?

Hace tiempo un compañero de trabajo, Juanse, me recomendó un vídeo de una persona que comentaba algunos conceptos algo alocados sobre la vida. En un mensaje de un compañero de la UNED esta semana he recibido un enlace al mismo vídeo por lo que aunque al principio me echó para atrás hay comentarios muy buenos en el vídeo que merece la pena ver.

Durante años, en las empresas en las que he estado siempre ha existido el mismo problema: las reuniones se eternizan. Se habla de muchos temas misceláneos y tras horas no se tiene la información clara sobre el tema principal y motivo por el que se organizó la reunión. ¿Cómo podemos mejorar esta situación?

Dando una vuelta por el sitio web de Ruby on Rails, he topado con la página de 37 signals, donde se podía ver la portada de un libro que han escrito y que se titula Rework.

En estos últimos días, hablando con colegas del tema de realizar proyectos/productos en los que pudiésemos tener mayor visibilidad, mayor participación, ya que somos la mano de obra que se encarga de su realización, llegamos a la redacción de esta carta:

Hace ya más de un año que escribí una entrada sobre ETL, donde comentaba los principios que lo fundan y algún que otro software disponible para realizar ETL. Revisando la entrada, me he dado cuenta de que el software que entonces encontré, ha cambiado bastante, incluso uno de ellos ha desaparecido como tal.

Mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham), el tema era: La deuda técnica en scrum, ¿lo revisamos?

Desde mi punto de vista, esto puede suponer una locura total y una falta de forma en lo que respecta al uso de un almacén de datos visto como tal. No obstante, hay sistemas de base de datos que implementan una capa de negocio bastante interesante, donde otros sistemas solo dan una opción de scripting que da algo de miedo.

En postgresql, por ejemplo, el sistema de lenguajes que se pueden usar e implementar para la creación de funciones: PL/pgSQL, PL/Tcl, PL/Python, PL/Perl, PL/PHP, PL/Java, PL/Ruby, ...; todos ellos se pueden ver en la página de documentación de PostgreSQL.

En todas las empresas en las que he trabajado, siempre surge un problema, cuando algo nuevo aparece si la persona que ha motivado su introducción no sabe su nombre: se la inventa. No suele ser un problema porque toda la empresa conoce el término, la tecnología o el elemento dentro de sus sistema por ese nombre, pero para nuevas personas en el proyecto, puede resultar frustrante, ¿qué nombre elegir mejor?

Este término, ETL, se acuña a la mayoría de transformaciones de datos que deben de realizar empresas para compatibilizar sus datos con los de sus proveedores y/o clientes.

Según se puede ver en la definición de la wikipedia BPM es una metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio.

Cuando una empresa tiene una actividad comercial, por ejemplo, basada en un almacén, con varios sistemas que requieren acceder a la base de datos para su manipulación (administrativos, atención al cliente, empleados de almacén...), cada uno con una misión específica, se deben de centralizar esa actividad de alguna forma para no caer en el problema de repetirnos a nosotros mismos (incumplir DRY) codificando una y otra vez lo mismo en varios programas distintos.

Cuando una empresa se forma, se intenta organizar el trabajo entre las pocas personas que la inician y si su estructura es buena y sus productos/servicios asequibles para el mercado, la empresa crece y con ella su personal. Es el inicio de los problemas.

Le he estado dando vueltas hoy a herramientas de Business Intelligence (Inteligencia de Negocio) tales como Pentaho y ver cómo están estructurados todos los departamentos de negocio que he visto en muchas empresas.